This invention relates to a method and apparatus for examining design integrity of an SoC (System-on-a-Chip) IC having a plurality of functional cores, and more particularly, to a method and apparatus for SoC design validation in which design validation can be evaluated as to an intended function of each core, timings in each core, interface among the cores, and an overall system operation of the SoC IC.
In the last 5-years, ASIC technology has evolved from a chip-set philosophy to an embedded core based system-on-achip (SoC) concept. These system-chips are built using predesigned models of complex functions known as xe2x80x9ccoresxe2x80x9d (also known as Intellectual Property or IP) that serve a variety of applications. These cores are generally available either in high-level description language (HDL) such as in Verilog/HDL (known as soft-core), or in transistor level layout such as GDSII (known as hard-core). A system-chip may contain combinations of hard and soft cores for on-chip functions such as microprocessors, large memory arrays, audio and video controllers, modem, internet tuner, 2D and 3D graphics controllers, DSP functions, and etc.
Many times, these cores are purchased from core provider companies and integrated together to make an SoC. When a core is purchased from outside, the core provider provides the design netlist along with the simulation testbench of the core. Thus, when the core is integrated in an SoC, it is desirable to directly apply the core""s testbench without any modification to verify its operation in the integrated SoC design.
At the present time, design is described in blocks and sub-blocks using a high-level language such as Verilog/VHDL and simulated by behavioral/gate-level Verilog/VHDL simulators. Such simulation is targeted to check the functionality before design is fabricated into a silicon IC. Design validation is one of the most important and difficult tasks in SoC design because without full functional verification design errors are neither found nor removed. Because of the slow simulation speed and large size of SoC design, SoC level design validation is almost an impossible task with the present day tools and methodologies.
Verification implies checking against an accepted entity. For system design, it means checking the design against the specification. Verification is done to verify that, during system design, the translation from one abstraction level to other is correct. The objective is to find out, within the practical limits, whether the system will work as intended after implementation and manufacturing the design. System-on-a-chip is a single hardware component with multiple embedded cores. Hence, design validation of SoC consists of verification of cores, verification of interconnects among the cores and verification of the combined system operation.
At the present time, along with the development of SoC specification, behavioral models are developed so that simulation testbenches can be created for design validation or the verification of the system operation. The system level verification is done based on the design hierarchy. First, the leaf level blocks, normally at the core level, are checked for correctness in a stand-alone way. Then, the interfaces between those cores are checked for correctness in terms of transaction types and in data contents. The next step is to run application software or equivalent testbenches on the fully assembled chip. This involves hardware/software co-verification (M. Keating and P. Bricaud, xe2x80x9cReuse methodology manualxe2x80x9d, Kluwer Academic Press, 1998; J. Stcunstrub and W. Wolf, xe2x80x9cHardware-software co-designxe2x80x9d, Kluwer Academic Press, 1997). Software can only be verified by runtime executions of the software code, and therefore, a hardware-software co-simulation has to be performed. Often a hardware prototype either in ASIC (application specific IC) form or using FPGAs (field programmable gate arrays) is also developed and used for the verification of the overall system operation.
FIG. 1 illustrates the core design at different levels of abstraction and what type of verification methodology is used today at each level. From the highest to lowest abstraction levels, FIG. 1 shows behavioral HDL level 21, RTL (register transfer language) level 23, gate level 25 and physical design level 27. Verification methods corresponding to such different abstraction levels are listed in a block 28 of FIG. 1. The basic types of verification tests may include the following:
(1) Compliance testing which is testing to confirm compliance to design specification.
(2) Corner testing which is testing for complex scenarios and corner cases such as in the minimum and maximum conditions in voltage, temperature and process.
(3) Random testing which is basically non-targeted testing that could detect very obscure bugs.
(4) Real code testing which is done by running a real application on the design so that any misrepresentation in functionality can be corrected.
(5) Regression testing which is done by running a collection of tests after any modification in the design. Each bug fix generally requires addition of a new test case with additional test conditions.
Development of testbench depends on the function of the core and the target SoC. For example, a testbench for a processor would execute a test program based on its instruction set, while a testbench for a bus controller interface core, such as a PCI core, would use bus functional models and bus monitors to apply stimulus and check the simulation output results. The problem in this approach is that the behavioral testbenches are extremely slow.
After generating the test cases (stimulus or pattern), it is required to check whether the output responses are correct or not. Today, it is done manually by looking at the output waveform, but as changes occur to the design, this manual checking becomes impossible. Another way to verify output responses is to run the actual software application, which is basically a hardware/software co-simulation. This approach is very inefficient in today""s computational resources. Further in such a testbench, actual transactions between the application and core are only a small fraction of the total cycles being simulated. Hence, only a small fraction of functionality is verified.
In SoC design, the interfaces between the cores need to be verified. Usually the interfaces have a regular structure with address and data connecting the cores either core-to-core or on-chip global buses. The interfaces also have some form of control mechanism and signals such as request/grant protocol and bus controller. The regular structure of these interfaces can be defined by the transaction of limited number of sequences of data and control signals.
Interface verification requires a list of all possible transactions at each interface, thus, it is an impossible task because all possible test cases cannot be generated. Thus, limited verification is done. After this limited verification, the next task is to verify that the core behaves correctly for all values of data and for all sequences of data that each core would receive. Such verification is again impossible, hence, a grossly incomplete verification is done today because all different data values in a transaction are prohibitively too large.
Timing verification is even harder task than functional verification. Static timing analysis is the most widely available method today. Static timing analysis is performed on representative netlist of cores that have been synthesized with various technology libraries. Static timing analysis tends to be pessimistic because false paths are not properly filtered out. Removal of false paths is a manual process and thus, it is subjected to errors. Gate-level simulation provides a reasonable check for these types of errors but it is not a complete solution since it would take excessive amount of time to develop stimulus and to simulate all the timing paths at the gate-level. Also, the worst case timing scenarios are not exercised in gate-level simulation, since they are too complex and numerous to be identified properly by the design engineer.
The main goal of SoC design validation is to verify the entire system the way it would be used by the end user. This requires full functional models of all cores (i.e. hardware models) and a reasonable amount of real system applications. If it is a new system, such applications may not exist. The major issue is the simulation speed. For example, even at RTL (register transfer language) level, booting up an operating system on a processor takes hours. To improve the simulation speed, one of the two methods is used; (a) higher level of abstractions to run the simulations faster, or (b) prototyping or emulation in hardware.
For higher abstraction models, RTL models are used for the functional cores, behavioral or ISA (instruction set architecture) models for memory and processor cores and bus functional models and monitors are used to generate and check transactions with communications blocks. For SoC such as a media processor, application codes are generated to run on it in the simulation environment. Very little can be done when applying software applications, it is limited to checking if the silicon (SoC chip) is functioning or completely dead and to find basic bugs. Today, errors are detected manually using bus monitors or by a sequence checker/monitor on the communications interfaces. However, the simulation speed is extremely slow, approximately 10 cycles per second that is too slow to run any reasonable size application.
When hardware and software are simulated in a concurrent way, it is called co-simulation. Hardware can be modeled in a C language function and the entire system can be executed like a single C language program. However, this is not design validation because it is not at the implementation level, but rather, it is a behavioral verification or a feasibility study. HDL/RTL description is required for the entire system validation since it represents the implementation of hardware components. Co-simulation requires communication between one or more HDL simulators and C/C++ programs (requiring a compiler, loader, linker and other pieces from the computer operating system). Thus, the additional problem in the co-simulation is the communication between different simulators.
All design teams attempt to make the first silicon fully functional, but more than 50% designs fail when put into the system for the first time. This is due to lack of system level verification or SoC level design validation. To reliably achieve success in the first attempt, more and more real applications should be simulated. As simulation time became unreasonably long, the only practical solution today is using silicon prototypes although it costs significantly. The available techniques are FPGA/LPGA and emulation.
For smaller designs, an FPGA (field programmable gate array) or LPGA (laser programmable gate array) prototype can be made. Although FPGA and LPGA lack the gate count capacity and speed of ASICs, they are good for smaller blocks or cores, but not suitable for the entire SoC. Several FPGAs can be interconnected on a circuit board and used to build a prototype of the entire SoC. In this case, if a bug fix requires re-partitioning of the SoC chip, interconnects between FPGAs would be changed, requiring a new circuit board, and hence the modifications are expensive and takes significant amount of time.
Emulation technology provides an alternative to a collection of FPGAs for large chips. It provides programmable interconnect, fixed board designs, relatively large gate counts and special memory and processor support. Emulation can give faster performance than the simulation if the entire design can be loaded into the emulation engine itself. However, it is still significantly slow in the execution speed compared to actual silicon. The emulation performance further degrades if a significant portion of the chip data or the testbench data is loaded on the host computer. The additional drawback of this method is its cost. All commercially available emulation systems today cost more than one million dollars.
When the design is too large (multi-million transistors), building a real silicon prototype and debug in the final system is the only available method today. In this situation, same silicon can be used for first several bugs without new silicon run. The whole process requires 2-3 silicon runs (fabrication cycles), while each run adds significant cost to the overall product development.
As in the foregoing, the existing technology cannot effectively test and validate SoC design in terms of performance, cost and speed. Therefore, there is a need in the semiconductor industry for a new method and apparatus which is capable of performing thorough SoC design validation with high speed and low cost.
Therefore, it is an object of the present invention to provide a method and apparatus for SoC design validation which is capable of performing thorough SoC design validation on each core function, interconnection between the cores, and entire system performance.
It is another object of the present invention to provide a method and apparatus for SoC design validation which is capable of performing thorough SoC design validation with high speed and low cost.
It is a further object of the present invention to provide a design validation station wherein SoC design validation is conducted to verify the overall functionality of the SoC.
It is a further object of the present invention to provide a method and apparatus which allows a user to debug a fault in the cores of the SoC much more easily than the present day systems.
The present invention provides a new method and apparatus for design validation or full functional verification that solves the present day difficulties of design validation of embedded cores based system-on-a-chip ICs. The inventors call it a xe2x80x9cdesign validation stationxe2x80x9d because it is used to verify the overall functionality of the SoC. The system architecture described in this application is very efficient, less costly and fundamentally different than any previously described system.
One aspect of the present invention is a method for design validation of an embedded cores based SoC (system-on-a-chip) in which a plurality of functional cores are integrated. This method includes the steps of: verifying individual cores to be integrated in an SoC[,] by using a physical silicon IC of each core and simulation testbenches [provided by a core provider] of each core; verifying interfaces between the individual cores, on-chip buses of the cores and glue logic [using] by using the silicon IC and simulation testbenches [developed by an SoC designer] and FPGA/emulation of the glue logic; verifying core-to-core timings and SoC level timing critical paths; and performing an overall design validation by using the silicon ICs and simulation testbenches of an overall SoC and application runs.
Another aspect of the present invention is an apparatus for design validation of the SoC. The apparatus includes a main system computer for interfacing with a user and controlling the overall operation of the apparatus for design validation, a plurality of verification units each of which receives testbench data from the main system computer and generates test patterns using the testbench data for testing a plurality of [functional] physical ICs (rather than simulated cores) having functions of the cores to be integrated in an SoC, and a system bus interfacing the main system computer with the plurality of verification units. In the apparatus of the present invention, a plurality of silicon ICs are connected to the verification units to receive the test pattern from the verification units and [generates] to generate response outputs [to be] that are evaluated by the verification units and main system computer, wherein each of the silicon ICs carries an inner structure and function identical to that of the corresponding functional core to be integrated in the SoC.